Behavioural Verification of Distributed Components

Component models provide a structured programming paradigm, and ensure a very good re-usability of programs. Indeed in component applications, dependencies are defined together with provided functionalities by the means of provided/required ports; this improves the program re-usability. Some component models and their implementations additionally keep a trace at runtime of the component structure and of their dependencies. Knowing how components are composed and being able to modify this composition at runtime provides great adaptation capabilities: the applications can adapt to evolution in the execution environment by changing the components taking part in the composition or their dependencies. GCM [3] has been proposed in the CoreGrid Network of Excellence, it is an extension of the Fractal component model [6] to better address large-scale distributed computing. GCM builds above Fractal and thus inherits from fractal: its hierarchical structure, the enforcement of separation between functional and non-functional concerns, its extensibility, and the separation between interfaces and implementation. The main extensions provided by GCM are: • GCM supports collective communications: one-to-many, and many-to-one. • GCM also comes with a support for autonomic aspects and better separation between functional and non-functional concerns: more precisely, in GCM non-functional concerns can also be defined as a component assembly. ProActive/GCM is a reference implementation of the GCM component model that has been implemented during the GridComp European project. It is based on the ProActive Java library and relies on the notion of active objects [9]. It is important to note that each component corresponds at runtime to an active object and consequently each component can easily be deployed on a separate JVM and can be migrated. Of course, this implementation relies on design and implementation choices relatively to the purely structural definition provided by the model. Even if the programming methodology entailed by active objects and GCM is way simpler than RMI-style of programming, bugs are still more frequent in distributed applications than in sequential ones. Indeed, even if our programming model prevent data race-conditions, race-conditions between communications and deadlocks can still exist. The complex interleaving of communications makes the reasoning on a distributed system difficult, even when the system is built from well separated components.